home *** CD-ROM | disk | FTP | other *** search
/ IRIX Base Documentation 1998 November / IRIX 6.5.2 Base Documentation November 1998.img / usr / share / catman / a_man / cat7 / imon.z / imon
Text File  |  1998-10-20  |  8KB  |  133 lines
  1.  
  2.  
  3.  
  4. IIIIMMMMOOOONNNN((((7777MMMM))))                                                              IIIIMMMMOOOONNNN((((7777MMMM))))
  5.  
  6.  
  7.  
  8. NNNNAAAAMMMMEEEE
  9.      imon - inode monitor device
  10.  
  11. SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
  12.      ####iiiinnnncccclllluuuuddddeeee <<<<ssssyyyyssss////iiiimmmmoooonnnn....hhhh>>>>
  13.      ////ddddeeeevvvv////iiiimmmmoooonnnn
  14.  
  15. DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
  16.      The inode monitor driver is a pseudo device driver which enables a user
  17.      level program to monitor filesystem activity on a file by file basis.
  18.      The application program expresses interest in specific files by means of
  19.      an _i_o_c_t_l request that specifies the pathname of the file and an
  20.      indication of what types of events are to be monitored.  As various
  21.      actions take place on a file in which interest has been expressed, _i_m_o_n
  22.      posts events through a queue that may be read via the _r_e_a_d system call.
  23.  
  24.    EEEEvvvveeeennnnttttssss
  25.      Calls to _r_e_a_d return an integral number of imon queue elements.  Each
  26.      queue element has the structure given below.
  27.  
  28.      typedef struct {
  29.           ino_t          qe_inode;  /* inode number of file  */
  30.           dev_t          qe_dev;         /* device of file  */
  31.           intmask_t qe_what;   /* what events occurred  */
  32.           } qelem_t;
  33.  
  34.      The qqqqeeee____iiiinnnnooooddddeeee is a key that uniquely describes every file within a
  35.      filesystem and matches the sssstttt____iiiinnnnoooo field of the file's _s_t_a_t structure (see
  36.      _s_t_a_t(4) ).  The qqqqeeee____ddddeeeevvvv field similarly matches the st_dev field of the
  37.      file's _s_t_a_t structure.  These two fields together uniquely describe a
  38.      file in the system.  The third field, qqqqeeee____wwwwhhhhaaaatttt, contains a bit-mask
  39.      describing what event or events took place on that file.  The possible
  40.      events are:
  41.  
  42.      IIIIMMMMOOOONNNN____CCCCOOOONNNNTTTTEEEENNNNTTTT   The contents or size of the file have changed.  This is
  43.                     typically caused by a _w_r_i_t_e(2) call made by some process.
  44.  
  45.      IIIIMMMMOOOONNNN____AAAATTTTTTTTRRRRIIIIBBBBUUUUTTTTEEEE The mode or ownership have changed on the file.  This is
  46.                     typically caused by a _c_h_o_w_n(2) or _c_h_m_o_d(2) system call.
  47.  
  48.      IIIIMMMMOOOONNNN____DDDDEEEELLLLEEEETTTTEEEE    The last link to the file has gone away.  When this event
  49.                     is sent, all interest in the file is implicitly revoked.
  50.                     Note that if a process has the file open when it is
  51.                     removed from the directory structure, this event will not
  52.                     be generated until the file is closed.
  53.  
  54.      IIIIMMMMOOOONNNN____EEEEXXXXEEEECCCC      The file represents an executable command and a process
  55.                     has started executing that command.  If multiple instances
  56.                     of the same command are subsequently started, an event is
  57.                     not generated.  Therefore, the IIIIMMMMOOOONNNN____EEEEXXXXEEEECCCC event only means
  58.                     that at least one process is executing from that file.
  59.                     When an interpreted executable (see_e_x_e_c_v_e(2)) is executed,
  60.  
  61.  
  62.  
  63.                                                                         PPPPaaaaggggeeee 1111
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70. IIIIMMMMOOOONNNN((((7777MMMM))))                                                              IIIIMMMMOOOONNNN((((7777MMMM))))
  71.  
  72.  
  73.  
  74.                     then IMON_EXEC events are generated both for the
  75.                     interpreted script and for the interpreter.
  76.  
  77.      IIIIMMMMOOOONNNN____EEEEXXXXIIIITTTT      The last process executing the file has exited.
  78.  
  79.      IIIIMMMMOOOONNNN____OOOOVVVVEEEERRRR      The _i_m_o_n event queue has overflowed.  When this occurs,
  80.                     the client process must re-express interest in each file
  81.                     to determine its true state.
  82.  
  83.    CCCCoooonnnnttttrrrroooollllssss
  84.      The following structure is used by the IIIIMMMMOOOONNNNIIIIOOOOCCCC____EEEEXXXXPPPPRRRREEEESSSSSSSS and IIIIMMMMOOOONNNNIIIIOOOOCCCC____RRRREEEEVVVVOOOOKKKKEEEE
  85.      controls described below.
  86.  
  87.      typedef struct {
  88.           char *         in_fname;  /* pathname */
  89.           struct stat *  in_sb;          /* optional status return buffer */
  90.           intmask_t in_what;   /* what types of events to send  */
  91.           } interest_t;
  92.  
  93.      IIIIMMMMOOOONNNNIIIIOOOOCCCC____EEEEXXXXPPPPRRRREEEESSSSSSSS
  94.                     Express interest in the file whose name is given in
  95.                     iiiinnnn____ffffnnnnaaaammmmeeee.  If iiiinnnn____ffffnnnnaaaammmmeeee represents a symbolic link, the
  96.                     action takes place on the link itself, not the file to
  97.                     which it points.  Only events in the bit-mask iiiinnnn____wwwwhhhhaaaatttt will
  98.                     be generated.  The iiiinnnn____ssssbbbb field optionally points to a
  99.                     _s_t_a_t(4) buffer that will be filled in with the current
  100.                     state of the file.  This allows the _i_m_o_n client to
  101.                     atomicly express interest and get the current state of a
  102.                     file.  Multiple calls may be made on the same file and
  103.                     have a cumulative effect.
  104.  
  105.      IIIIMMMMOOOONNNNIIIIOOOOCCCC____RRRREEEEVVVVOOOOKKKKEEEE Revoke interest in the file whose name is given by
  106.                     iiiinnnn____ffffnnnnaaaammmmeeee.  The iiiinnnn____wwwwhhhhaaaatttt field is used to determine which
  107.                     interests will be revoked.  As with IIIIMMMMOOOONNNNIIIIOOOOCCCC____EEEEXXXXPPPPRRRREEEESSSSSSSS,
  108.                     multiple calls may be made on the same file and have a
  109.                     cumulative effect.
  110.  
  111.      IIIIMMMMOOOONNNNIIIIOOOOCCCC____QQQQTTTTEEEESSSSTTTT  Returns the number of events waiting to be read in the
  112.                     event queue.
  113.  
  114. BBBBUUUUGGGGSSSS
  115.      Files in an NFS mounted filesystem will only generate events for things
  116.      that happen as a result of local activity; changes made remotely on the
  117.      NFS server will not be seen through _i_m_o_n.
  118.  
  119. CCCCAAAAVVVVEEEEAAAATTTTSSSS
  120.      The _i_m_o_n driver is intended to be used only by the file access monitoring
  121.      daemon (fam) and the interface is likely to change in future releases.
  122.      Client programs should communicate with fam for monitoring services, not
  123.      with _i_m_o_n directly.
  124.  
  125.  
  126.  
  127.  
  128.  
  129.                                                                         PPPPaaaaggggeeee 2222
  130.  
  131.  
  132.  
  133.